Back to the Rhythm Universe download page

Rhythm Universe Postmortem

Here, I'll be doing a "postmortem," or a reflection on the roller coaster ride that was Rhythm Universe's development. It's in the style of GameDeveloper magazine's postmortems...because wouldn't it be cool if this were actually featured in that magazine? Hehehehe!

Uh... Ahem. So:

What Went Right

1. Scope. RhyU was never meant to be a massive, expansive game. In fact, it was originally pitched as a student project back when I was at Full Sail University. Because of that, it had to be scoped small so that we could convince the professors that we could finish it within a tight deadline. So it was important for RhyU to have enough meat on it to be engaging (which I think the gameplay accomplishes, being rather unusual) but not so fancy and littered with features that the player forgets what the main draw is.

2. Rapid prototyping. Being the only member on it, my development team was very agile. For all but a few days during development, the build was always in a stable state at the end of the day. If I needed to try out a new feature, I could implement a quick and dirty version of it and review it, and from there decide if I wanted to tweak it or go ahead with it. Scripting, although in primitive XML, allowed me to quickly change specific variable values, like default speeds and positions, until I was content [enough].

3. Assets. Getting media into a game is a challenge--for teams, small groups, and individuals. That’s usually due to designers speaking a different language than artists, who speak a different language than programmers (to put it lightly). That whole pipeline was avoided here: I was the designer, artist, and programmer. So communication was easy. Conversations consisted of: “Kna mean?” “I feel you.” “Aight let’s do dis.” And that was that.
    Basically, I never had to convey an idea to someone else who would create a tangible version of the idea. This is an important skill, I know, but it was conveniently avoided here. I always knew exactly how something should look or sound, or how long a transition should be, or where in the game it should exist. So if something seemed lacking, like it was just missing that extra “oomph,” I knew how to fix it--even if I couldn’t explain it.
    Tools-wise, everything was cheap or free. I got Photoshop with my Full Sail student discount, adapted a Maya model exporter I wrote in a tools programming class, discovered Cakewalk’s Music Creator (the very affordable and surprisingly effective alternative to Sonar), and of course, Audacity. Thanks to those, and some leftover assets from my school final project (Ace of Space), I was able to give RhyU a healthy asset package.

4. Feedback. You can’t create games in a vacuum. I’m not the first to say this, but I’ll be the first to agree. That’s why I encouraged friends and colleagues to check out early versions of the game, and I would iterate on my design as necessary. Other people catch things that I either overlook or just never think are a big deal (when they really are).
    Because the game concept was unusual, gameplay was bound to be rough at first. But thanks to input from others, I was able to streamline it considerably over time. For instance, right-click used to release the sun’s innermost planet. This turned out to be a pretty useless and limiting function, but I was having trouble thinking up something better. That’s when a comment from a friend of mine sparked a new idea which turned out to be a much kinder and dare I say more “fun” alternative.

5. Being the only one. No project management. No meetings. No bureaucracy. Just about all of my time on the project resulted in something moving forward--and not just an illusion of something moving forward. And if there was a bug in some far-reaching sector of the code base, chances are I knew what it was and would fix it very quickly--because I was the one who caused it in the first place! It’s this godlike control over the game that let me do whatever I wanted, whenever I wanted, however I wanted, and I didn’t have to explain why I was doing it. But is it healthy to have that much power?

What Went Wrong

1. Being the only one. Double-edged sword if there were one. As awesome as I just got through saying it was to be the only one on the project, the downside is, I’m the only one on the project. I can’t offload tasks like extending the particle engine functionality to include odd-shaped firework effects, or playing the tutorial a thousand times to find bugs, to someone else. Because I was that someone else. And let me confirm that there’s a lot to do--even in a not-very-massive game such as RhyU.     Sure, sometimes teams have communication problems, but when you got two or even three people working on separate parts of the game that can later be merged together (without much fuss), you have a game-making machine. And let me also confirm that two heads are indeed better than one (even if I am the one).

2. Programming on a whim. “You know what would be cool?” Yes, the feature creep… Oh, I can list a dozen and a half features that could’ve, would’ve and should’ve made it into RhyU. Overall, I think I did pretty well resisting the temptations of those extra features, but the thing was, I had no one there to keep me in check. So I did indeed spend some time on stuff that never saw the light of day. But the worst part was, it was something I just decided on a whim; I didn’t flesh it out, I didn’t write it in a document, and I didn’t even convince myself that it was worth the time. I was just all, “this could be cool; let me see how it turns out in the game; I’ll just design it as I program it!” Stupid! But I had no one else there to smack me upside the head, so it happened.

3. No scheduling. Absolutely none. And why would I schedule stuff? It’s my project. It’s done when it’s done. Right? See, even if that’s the case, it still pays to schedule. Not just because your boss says so; it’s really actually practical--like vegetables are really actually good for you. (Yeah, I know, but they are.) It gives you an idea of what’s feasible and really makes you think, “gee, how long will it take me to do that? And is it worth it?” If nothing else, it gives you that extra kick in the pants to get it done and avoid slacking or doting on something that doesn’t need attention.
    In my defense, I did write out little “lists” of things I needed to get done next. But I never put hard deadlines on them. The only real deadline I had was GDC; I said “I’ll have the game out by the time GDC starts!” And I did. But because I didn’t schedule, I felt stressed out to get it all done. And being stressed out on your free time is never ever, ever fun--and shouldn’t happen.

4. Half-baked code. This isn’t me saying I’m a lousy programmer. I’m nowhere near the best, but I’m good. I’m also good at writing code that “gets it done” but has troublesome side effects--like allergy medication. The thing is, I know this at the time and I’m, like, “yeah, I’ll have to come back to this later.” But then I try to forget about it--like maybe it’s not a problem and I can just ignore it and no one will ever notice.
    Nope. There’s no cheating the system. You can’t build a house with rotting wood, and you can’t code a game engine with rotting code. It will collapse. And it won’t be pretty. So get it done right, and try to keep temporary fixes to a minimum.

5. Being ambiguous. When you design a game, you do it like this: You brainstorm, get struck by an idea, explain why it’s fun, then flesh it out. I understand that’s general, but it’s the gist of things. Well, Rhythm Universe didn’t get its due process.
    The concept was originally conceived by me, but at the time, I was with my Full Sail final project group and we were going to pitch it as “Celestial Harmony” (along with our other idea, Ace of Space) for our final project. The “fleshing out” was somewhat of a joint process--but even then, the game is quite different now than what it was at that time. The problem here is that we never were able to concisely explain what the game was about--and more importantly, why it was fun.
    I did a good job getting across how you play and fleshing out details. But I missed the mark on the “one-sentence description” that’s ever so important to publishers. And if you asked me why the game was fun, I would probably stutter and spew a bunch of garbage that didn’t really save the game. That’s because I never came up with that golden summary, the “tree nugget,” at the get-go--rather, I was designing the game as I was implementing it, not unlike those Youtube videos that play faster than they can load. As I was doing that, I realized why Ace of Space got picked over RhyU; if you’re going with something new and experimental, you had better convince the suits (and yourself) why it’s a worthy cause. Don’t just be a idealist newbie with stars in your eyes.